*******************************************************************
    Overview and discussion of features added to TOLEAutoClient V1.1
    *******************************************************************

*********************************
IMPROVED ERROR/EXCEPTION HANDLING
*********************************

   Messages displayed for exceptions raised while attempting to
start up a server have been improved to be more descriptive,
and additional error code information is available for OLE method
calls and property accesses.  You can also handle failures of
method calls and property accesses via Delphi's exception mechanism.
Refer to the section of OLEAUTO.TXT concerning error handling for
a full discussion of the error information available and for
an illustration of exception-based method failure handling.  Also
see OLEAUTO.INT for definitions of the relevant error code values
and of their type, which is HRESULT.

**********************************
NEW SUPPORT FOR IN-PROCESS SERVERS
**********************************

   This release allows you to control OLE Automation servers that
are implemented as 16-bit DLLs (i.e., 16-bit in-process servers),
in addition to both 16-bit and 32-bit .EXE servers ("local" servers).
You don't need to do anything special to control such servers, since
the CreateObject constructor for TOleObject will automatically try
to start up the server as a local (.EXE) server and if that fails
will then try to start it as an in-process (.DLL) server.

   However, to avoid the slight speed penalty associated with this
two-step process, you can use the alternative constructor
CreateInProcessObject(ProgID : String) for your mirror class
derived from TOleObject.  This constructor simply attempts to
activate the server as an in-process server if possible.  If
you are sure your server is an in-process server then using
CreateInProcessObject instead of CreateObject will be faster.

   If your 16-bit Delphi application is to run under Windows 95,
it can control local servers (i.e., one implemented as an
.EXE) regardless of whether the server is implemented as a 16-bit
or a 32-bit application.  This is thanks to the Windows OLE
mechanism.  However, it will not be able to control a 32-bit
in-process server (that is, one implemented as a 32-bit .DLL);
this limitation is also a result of the architecture of 32-bit
Windows.

   No sample in-process server is supplied with this component,
since controlling one presents no particular difficulties.
Although you cannot readily write an in-process server in 16-bit
Delphi (or an .EXE server either, for that matter), other
compilers and languages do support this, and in-process servers
generally result in a faster implementation.  The most widely-
available commercial in-process servers are the ones supplied by
Microsoft that implement versions 2.5 and 3.0 of the Jet (TM)
database engine.  Regrettably, however, Jet 3.0 uses 32-bit
technology and Jet 2.5 contains internal logic that generates
an E_ACCESSDENIED error when you attempt to access any
meaningful properties of the server identified by the
DAO.DBEngine ProgID, so this component doesn't provide a
way to communicate with Microsoft Access (TM) databases.

**********************************
CONTROLLING INSTANCES OF SERVERS
THAT ARE ALREADY ACTIVE & RUNNING
**********************************

   There are situations in which you may want to control
OLE Automation servers that are already running, either
as separate applications or as OLE server applications
inside a Delphi TOLEContainer component.  This version
of TOLEAutoClient allows you to do so.  In order to
"hook into" a running instance of a server, instead of
using the CreateObject constructor for your mirror class
derived from TOLEObject you use the new alternative
constructor GetObject(ProgID : String).  This constructor
will locate a running instance of the server, if there
is one, and enable your mirror class object to control it.
***NOTE 1***:  Microsoft Word (versions 6.0 and 7.0) operates
differently from most OLE Automation servers in this regard.
Calling GetObject('word.basic') will not work to activate an
already-running instance of Word -- this is a documented
"feature" of Word.  However, if you simply use the
CreateObject('word.basic') constructor instead, then if an
instance of Word is already running the Windows OLE subsystem
will automatically locate one such instance and you will be
able to control it.

   Refer to the accompanying sample application XLOLE5.ZIP
for an illustration of the use of GetObject.
***NOTE 2***:  The XLOLE5 example WILL NOT WORK if you are
running Excel 7 (the 32-bit Office 95 application) under
Windows 95.  The technical reason for this is that the
TOLEObject.GetObject constructor uses the Windows GetActiveObject
API call internally in order to "hook into" a running instance,
and this API does not work correctly for 32-bit servers when
called from 16-bit applications.  This limitation is a "feature"
of Windows 95.